Data federation with industrial control systems

ABSTRACT

An organizational model of a hierarchical system can be distributed across various elements of an enterprise. Such elements include representations of the system that are maintained on higher-level business servers and other representations that serve control elements of the system such as programmable logic controllers and/or other industrial control components. In one aspect, an industrial automation system is provided. The system includes at least one controller to instantiate a portion of an organizational hierarchy. A communications component in the controller interacts with at least one other portion of the organizational hierarchy to facilitate data exchange and control between various components of an enterprise.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/239,937, filed on Sep. 30, 2005, and entitled “DATA FEDERATION WITHINDUSTRIAL CONTROL SYSTEMS,” the entirety of which is incorporatedherein by reference.

TECHNICAL FIELD

The subject invention relates generally to industrial control systemsand more particularly to distributing and manipulating data across datahierarchies that can be shared between organizational models andindustrial control systems.

BACKGROUND

Industrial controllers are special-purpose computers utilized forcontrolling industrial processes, manufacturing equipment, and otherfactory automation, such as data collection or networked systems. At thecore of the industrial control system, is a logic processor such as aProgrammable Logic Controller (PLC) or PC-based controller. ProgrammableLogic Controllers for instance, are programmed by systems designers tooperate manufacturing processes via user-designed logic programs or userprograms. The user programs are stored in memory and generally executedby the PLC in a sequential manner although instruction jumping, loopingand interrupt routines, for example, are also common. Associated withthe user program are a plurality of memory elements or variables thatprovide dynamics to PLC operations and programs. Differences in PLCs aretypically dependent on the number of Input/Output (I/O) they canprocess, amount of memory, number and type of instructions, and speed ofthe PLC central processing unit (CPU).

In a more macro sense than the controller, businesses have become morecomplex in that higher order business systems or computers often need toexchange data with such controllers. For instance, an industrialautomation enterprise may include several plants in different locations.Modern drivers such as efficiency and productivity improvement, andcost-reduction, are requiring manufacturers to collect, analyze, andoptimize data and metrics from global manufacturing sites. For example,a food company may have several plants located across the globe forproducing a certain brand of food. These factories in the past werestandalone, with minimum data collection and comparison of metrics withother similar factories. In the networked world of today, manufacturersare demanding real-time data from their factories to drive optimizationand productivity. Unfortunately, conventional control systemsarchitectures are not equipped to allow a seamless exchange of databetween these various components of the enterprise.

SUMMARY

The following presents a simplified summary in order to provide a basicunderstanding of some aspects described herein. This summary is not anextensive overview nor is intended to identify key/critical elements orto delineate the scope of the various aspects described herein. Its solepurpose is to present some concepts in a simplified form as a prelude tothe more detailed description that is presented later.

An organizational model and addressing mode is provided that enablesdata to be automatically and efficiently exchanged from various layersof an organization, across organizational boundaries, and/or exchangedbetween lower-level control entities to upper-tiers of the organization.In one aspect, a hierarchical model of an organization is distributedacross control systems and other components of the organization such asbusiness computers. Such hierarchy can be stored in an instantiation ofa controller which is also accessible by the controller. This enablesexternal applications to address data in the controller via a controllernamespace and/or via an organization hierarchy such as provided by ahierarchical plant model, for example. Portions of the hierarchy can beimplemented in the controller without being connected to the centralsystem. This enables distributed development by multiple users such asoutside equipment manufacturers (OEMs).

The organizational hierarchy can also include other organizationalunits, controller scoped tags, programs with associated program scopedtags, add-on instructions, routines, operator interface screens, and/oruser defined information such has procedures and help files, forexample. A local hierarchy stored in a controller can be connected tothe system hierarchy via a “mount point.” The “mount point” can beconnected with a particular location in the system hierarchy during aconfiguration operation which associates the respective controller witha specific organizational project.

To the accomplishment of the foregoing and related ends, certainillustrative aspects are described herein in connection with thefollowing description and the annexed drawings. These aspects areindicative of various ways which can be practiced, all of which areintended to be covered herein. Other advantages and novel features maybecome apparent from the following detailed description when consideredin conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram illustrating data federation in anorganizational data model.

FIG. 2 is a diagram illustrating an example organizational hierarchy.

FIG. 3 is a diagram illustrating an example business model andhierarchical data representation that has been federated across anenterprise and control systems.

FIG. 4 is a diagram illustrating a flat and hierarchal datarepresentation for a controller.

FIG. 5 is a diagram illustrating a mount point for a control systemhierarchy.

FIG. 6 is a diagram illustrating multiple mount points for a controlsystem hierarchy.

FIG. 7 is a diagram illustrating multiple mount point for a controlsystem hierarchy and combined naming conventions.

FIG. 8 is a diagram illustrating an example system for processing modeldata structures.

FIG. 9 is a flow diagram illustrating a control data and enterprisefederation process.

FIG. 10 illustrates exemplary hierarchies that can be utilized inconnection with the hierarchically structured data model.

FIG. 11 illustrates exemplary hierarchies that can be utilized inconnection with the hierarchically structured data model.

FIG. 12 illustrates an exemplary combination of hierarchies.

FIG. 13 illustrates an exemplary combination of hierarchies.

DETAILED DESCRIPTION

An organizational model of a hierarchical system can be distributedacross various elements of an enterprise. Such elements includerepresentations of the system that are maintained on higher-levelbusiness servers and other representations that serve control elementsof the system such as programmable logic controllers and/or otherindustrial control components. In one aspect, an industrial automationsystem is provided. The system includes at least one controller toinstantiate a portion of an organizational hierarchy. A communicationscomponent in the controller interacts with at least one other portion ofthe organizational hierarchy to facilitate data exchange and controlbetween various components of an enterprise.

It is noted that as used in this application, terms such as “component,”“hierarchy,” “model, ” and the like are intended to refer to acomputer-related entity, either hardware, a combination of hardware andsoftware, software, or software in execution as applied to an automationsystem for industrial control. For example, a component may be, but isnot limited to being, a process running on a processor, a processor, anobject, an executable, a thread of execution, a program and a computer.By way of illustration, both an application running on a server and theserver can be components. One or more components may reside within aprocess and/or thread of execution and a component may be localized onone computer and/or distributed between two or more computers,industrial controllers, and/or modules communicating therewith.

Referring initially to FIG. 1, a system 100 illustrates data federationconcepts in an organizational data model. A hierarchical data model 110is illustrated having various nodes and branches that store data atmultiple locations throughout the system 100. Such model 110 can bedistributed across a network 114 to provide a collective or federateddatabase. As illustrated, an enterprise 120 may have one or morecomputers or network components that communicate across the network 114to one or more industrial control components 130 such as programmablelogic controllers (PLCs) 130. Thus, the data hierarchy 110 having datanodes and branches can be managed as a singular or collective entitywhile being viewed, managed and distributed across substantially all orportions of the enterprise 120 and/or PLC 130.

The system 100 enables combining organizational information called anorganizational or hierarchical data model 110 which represents a commonmodel of a plant that can be based in the S88 or S95 model, for example,and is distributed among computers of the enterprise 120 and industrialcontrollers 130, for example. The model 110 can be viewed as anOrganizational Model—a tree-like hierarchical and heterogeneousstructure of organizational Units. For instance, respectiveOrganizational Units may include other Organizational Units.Organizational Units can be either physical locations (e.g., Site, Area)or logical grouping node or collection (e.g., Enterprise as a collectionof Sites). The nodes in the organizational hierarchy or model 110 canhave associated items representing the plant's production and controlequipment, tags, backing tags (e.g., Alarm & Event and AOI objects),programs, equipment phases, I/O devices, and other application relatedentities. These organizational units thus can form an application viewof the user's system.

A typical system 100 can assign the upper levels of the hierarchy suchas an Enterprise node and site to a computer system and the lower levelssuch as area, line, cell and machine could be contained in multipleindustrial controllers each of which can include components which aremembers of one or more organization units such as area or area model. Anorganization unit such as area can contain components from one or morecontrollers. To ease the integration of data with information technology(IT) applications, methods are provided for defining various datastructures in the IT space and translating those to the controller and amethod using transactions to connect the controller and IT versions ofthe structure.

Before proceeding, it is noted that the enterprise 120 can includevarious computer or network components such as servers, clients,communications modules, mobile computers, wireless components, and soforth which are capable of interacting across the network 114.Similarly, the term PLC as used herein can include functionality thatcan be shared across multiple components, systems, and or networks 114.For example, one or more PLCs 130 can communicate and cooperate withvarious network devices across the network 114. This can includesubstantially any type of control, communications module, computer, I/Odevice, Human Machine Interface (HMI)) that communicate via the network114 which includes control, automation, and/or public networks. The PLC130 can also communicate to and control various other devices such asInput/Output modules including Analog, Digital, Programmed/IntelligentI/O modules, other programmable controllers, communications modules, andthe like.

The network 114 can include public networks such as the Internet,Intranets, and automation networks such as Control and InformationProtocol (CIP) networks including DeviceNet and ControlNet. Othernetworks include Ethernet, DH/DH+, Remote I/O, Fieldbus, Modbus,Profibus, wireless networks, serial protocols, and so forth. Inaddition, the network devices can include various possibilities(hardware and/or software components). These include components such asswitches with virtual local area network (VLAN) capability, LANs, WANs,proxies, gateways, routers, firewalls, virtual private network (VPN)devices, servers, clients, computers, configuration tools, monitoringtools, and/or other devices.

In addition to various hardware and/or software components, variousinterfaces can be provided to manipulate the hierarchical ororganizational data model 110 where various examples are illustrated inmore detail below. This can include a Graphical User Interface (GUI) tointeract with the model 110 or other components of the hierarchy such asany type of application that sends, retrieves, processes, and/ormanipulates factory or enterprise data, receives, displays, formats,and/or communicates data, and/or facilitates operation of the enterprise120 and/or PLCs 130. For example, such interfaces can also be associatedwith an engine, server, client, editor tool or web browser althoughother type applications can be utilized.

The GUI can include a display having one or more display objects (notshown) for manipulating the model 110 including such aspects asconfigurable icons, buttons, sliders, input boxes, selection options,menus, tabs and so forth having multiple configurable dimensions,shapes, colors, text, data and sounds to facilitate operations with themodel 110. In addition, the GUI can also include a plurality of otherinputs or controls for adjusting and configuring one or more aspects.This can include receiving user commands from a mouse, keyboard, speechinput, web site, remote web service and/or other device such as a cameraor video input to affect or modify operations of the GUI.

Before proceeding, it is noted that FIGS. 3-8 are directed to exemplaryhierarchies and data arrangements. It is to be appreciated however thansubstantially any data hierarchy that is distributed across anenterprise or business and/or shared across an industrial control systemis within the scope contemplated herein.

Referring now to FIG. 2, an exemplary hierarchical structure 200 whichcan be utilized in connection with the hierarchically structured datamodel described herein is illustrated. For example, the data model canfacilitate nested structures, thereby mitigating deficiencies associatedwith data models that employ flat namespaces although flat namespacescan be employed as well. The example structure 200 includes anenterprise level 202, where a particular enterprise can be representedwithin data structured in accordance with a hierarchical data model.Beneath the enterprise level 202 can be a site level 204, so that aparticular factory (site) within an enterprise can be represented withina data packet. Beneath the site level 204 an area level 206 can exist,which specifies an area within the factory that relates to the data. Aline level 208 can lie beneath the area level 206, wherein the linelevel 208 is indicative of a line associated with particular data.Beneath the line level 208 a work-cell level 210 can exist, therebyindicating a work-cell associated with the data. Utilizing a nested,hierarchical data model, PLCs can become more aware of data associatedtherewith. Furthermore, the hierarchy 200 can be customized by an ownerof such hierarchy. For instance, more granular objects/levels can bedefined within the hierarchy 200.

Turning to FIG. 3, an example business model 300 and hierarchical datarepresentation is illustrated that has been federated across anenterprise and control systems. In this example, an enterprise 310 isrepresented in the model 300 which is at the highest levels of anorganization. In this specific example, a commodity such as potato chipsare produced by the enterprise. As can be appreciated, higher or lowerlevels than the enterprise 310 can be represented in the model 300.Beneath the enterprise level, two plants are represented at a site level314 (e.g., one plant in Dallas and another in Detroit) although more orless than two shown can be employed. At 320, an area of a site includessome of the automated manufacturing processes for the site 314 such asslicing, washing, frying and packaging in this example.

From the respective area level 320, a line level 330 can be representedwhich includes equipment (further divided into work-cell), controllers,production components, segment components, and miscellaneous componentssuch as training elements, quality control data, and maintenance data.At a control level 340, logic processors that execute sequentialfunction charts or ladder logic are represented. Thus, from the highlevel enterprise view 310, data from the control view 340 is aggregatedand federated from the top down where the data model shows a unifiedview of data that is distributed across remote or local geographiclocations via network communications yet represented as a singular datamodel 300. At production and segment levels 350, components forprocessing data include work order elements, material managers,equipment sequencers, and production sequencers that may execute onmachines such as batch processors or servers, for example.

FIG. 4 illustrates flat and hierarchal data representations 400 for acontroller. In this aspect, controller data representations can beintegrated with hierarchical enterprise elements described above. Here,two views are shown. A flat representation at 410 shows a program enginethat can start and stop two motors. A hierarchical view 420 of the samedata structure 410 can be represented in the controller as well. Ingeneral, portions of an organizational hierarchy are stored in a runtimeinstantiation of a controller's operating environment which isaccessible by a communications layer of the controller (e.g., controllerforeground loop interfacing to a TCP/IP or Control Net stack). This willenable an external application executing at other levels of thehierarchy to address data in the controller via the flat controller namespace at 410 and/or via the organizational hierarchy at 420. As can beappreciated, portions of the hierarchy can be implemented in thecontroller without being connected to a central system. This enablesdistributed development by multiple users such as OEMs and systemsdesigners, for example. The organizational hierarchy can also includeother organizational units, controller scoped tags, programs withassociated program scoped tags, add-on instructions, routines, operatorinterfaces, and/or user defined information such has procedures and helpfiles, for example.

FIGS. 5-7 illustrate a mount point examples for control systemhierarchies. Mount points represent where in a distributed datahierarchy the controller is responsible for maintaining data at or belowsuch level of mount point. Data above such level can be stored onenterprise components such as client or server computers in theenterprise. As illustrated in FIG. 5, the local hierarchy in acontroller is connected to the system hierarchy 500 via a “mount point”at 510. This “mount point” 510 can be connected with a particularlocation in the system hierarchy during a configuration operation whichassociates this controller with a specific hierarchical project. Also,it is noted that the mount point 510 can be positioned at differentportions of the hierarchy 500. FIG. 6 shows a single controller 600 thatsupports multiple “mount points” at 610 and 620 which can be mounted atdifferent levels of the system hierarchy. At FIG. 7, an organizationunit such as area 700 can be composed of components from multipleindustrial controllers at 710 and 720. It is noted that organizationunits from multiple controllers with the same name can be combined.

FIG. 8 illustrates an example system 800 for processing model datastructures. The system 800 includes an enterprise computer 810, anapplication 820 for modifying data structures, configuration components830, and one or more control racks 840. In general, an IT developer viaan application can define a data structure 820 which can be deployed inthe controller 840. The definition can be in the form of an XML filethat describes the data structure, and the meaning for each of therespective members. This XML description could also be combined withother descriptions which would form a set of system structures. Thesedefinitions could be stored in a file which can be distributed to remoteusers with separate copies of the configuration software 830, ifdesired. A control engineer could then create instances of these systemstructures and fill in the data to enable sending the data to the ITapplications 820. These system structures may be based on plant datastandards such as S88 and S95, for example although other standards canbe applied. The control system can also have a mechanism to enable acontroller to originate a transactions based on an instruction in thecontroller that uses a system data structure as defined herein. Theorganizational structure or model can provide a way to indicate where acontroller variable should be public or private and if public whether itcan be written. Generally, only the subset of controller tags specifiedas public should appear in the organizational hierarchy.

FIG. 9 illustrates an organizational model and communications process900. While, for purposes of simplicity of explanation, the methodologyis shown and described as a series of acts, it is to be understood andappreciated that the methodology is not limited by the order of acts, assome acts may occur in different orders and/or concurrently with otheracts from that shown and described herein. For example, those skilled inthe art will understand and appreciate that a methodology couldalternatively be represented as a series of interrelated states orevents, such as in a state diagram. Moreover, not all illustrated actsmay be required to implement a methodology as described herein.

FIG. 9 illustrates a control model and communications process 900.Proceeding to 910, a one or more data structures are defined within thedomain of a controller. This includes storing portions of a hierarchicalmodel in a runtime instantiation of a controller or component associatedwith a controller. Such structures can be configured with controllerconfiguration software for defining address locations for variouscomponents and network data. At 920, respective data structures definedat 910 are associated with a communications layer of the controller orcontrol components. The layer can communicate with substantially anytype of network including factory networks, global networks such as theinternet, wireless networks, and so forth. At 930, portions of theorganizational hierarchy that are stored on the controller can becommunicated and interacted with other enterprise components acrossrespective networks. This can include exchanging data from variousportions of the enterprise over the network at different nodes and pathsof the hierarchy or model. At 940, data for the enterprise and controlsystems are aggregated at a particular node or at a given networklocation. This could include aggregating or collecting, viewing, orcollecting data at a network computer that communicates with the variousdata nodes of the enterprise and control hierarchy and then presentingsuch data at a display interface in a hierarchical form.

At 950, data is managed across the enterprise or organization via thehierarchical organization model. This can include viewing upper layersof the organization in higher level nodes of the hierarchy, where suchlayers may conform to such standards as S88 or S95 as previously noted.Data structures can be defined which exchange data between substantiallyall layers of an organization from lower-level control and configurationlayers on a network to higher level data nodes of the enterprise.Respective nodes can be adapted with varying levels of security tocontrol the type of human or machine access to a data node that may beavailable from different portions of the hierarchy.

Now turning to FIG. 10, hierarchical representations that can beemployed in connection with a schema employed by programmable logiccontrollers to facilitate use of a hierarchically structured data modelare illustrated. The hierarchies illustrated in this figure relate toequipment hierarchies, which can be integrated with procedurehierarchies to generate a robust representation of a plant (which isincorporated within a schema for use in connection with industrialcontrollers). A first hierarchy 1000 illustrates a representation ofequipment within a plant given disparate processes. For instance, ahierarchy in accordance with a batch process can include arepresentation of an enterprise, site, area, process cell, unit,equipment module, and control module. In contrast, a hierarchicalrepresentation of equipment within a continuous process can includerepresentations of an enterprise, site, area, production unit,continuous unit, equipment module, and control module. In still moredetail, an enterprise can represent an entirety of a company, a site canrepresent a particular plant, an area can represent a portion of theplant, a process cell can include equipment utilized to complete aprocess, a unit can relate to a unit of machinery within the processcell, an equipment module can include a logical representation ofportions of the process cell, and the control module can include basicelements, such as motors, valves, and the like. Furthermore, equipmentmodules can include equipment modules and control modules can includecontrol modules. Thus, as can be discerned from the figure, fourdisparate hierarchical representations can be employed to representequipment within batch processes, continuous processes, discreteprocesses, and inventory.

A second hierarchy 1002 can be utilized that represents each of theaforementioned hierarchical representations. The hierarchy 1002 caninclude representations of an enterprise, a site, an area, a workcenter, a work unit, an equipment module, and a control module. Thus, acommon representation can be generated that adequately represents thehierarchy 1000. For purposes of consistent terminology, data objects canbe associated with metadata indicating which type of process they areassociated with. Therefore, data objects can be provided to an operatorin a form that is consistent with normal usage within such process. Forexample, batch operators can utilize different terminology than acontinuous process operator (as shown by the hierarchy 1000). Metadatacan be employed to enable display of such data in accordance with known,conventional usage of such data. Thus, implementation of a schema inaccordance with the hierarchy 1002 will be seamless to operators.Furthermore, in another example, only a portion of such representationcan be utilized in a schema that is utilized by a controller. Forinstance, it may be desirable to house equipment modules and controlmodules within a controller. In another example, it may be desirable toinclude data objects representative of work centers and work unitswithin a controller (but not equipment modules or control modules). Theclaimed subject matter is intended to encompass all such deviations ofutilizing the hierarchy 1002 (or similar hierarchy) within a controller.

Now referring to FIG. 11, standard hierarchies that can be utilized torepresent procedures and equipment are illustrated. In particular, ahierarchy 1100 represents procedures that can exist within a batchprocess. For instance, a procedure can relate to a high-level procedure,such as creation of a pharmaceutical drug. A unit procedure can be morespecific, such as adding particular chemicals to a mix by way of aparticular unit. A unit operation can be still more specific, and aphase can be yet more specific (relating to operation of low-levelmachines). For instance, a phase can relate to various states which canexist with respect to low-level equipment, such as stopping, starting,and pausing a motor, opening and closing a valve, and the like. Ahierarchy 1102 relating to a representation of equipment in, forexample, a batch process is displayed adjacent to the hierarchy 1100.The representations within the hierarchy 1102 were described in greaterdetail with respect to FIG. 10.

Now turning to FIG. 12, a hierarchy 1200 that represents one possibleintegration of the hierarchies 1100 and 1102 (FIG. 11) is illustrated. Aunit (such as a work unit described in FIG. 10) can be associated withan equipment procedure, an equipment unit procedure, an equipmentoperation, and an equipment phase). Thus, the procedures, operation, andphase can be associated with a particular work unit. An equipment modulecan be associated with one or more equipment phases, and can be above acontrol module in the hierarchy. Referring Briefly to FIG. 13, ahierarchy 1300 that can be utilized in connection with equipment controlis illustrated. The hierarchy is substantially similar to that describedwithin the unit portion of the equipment unit. As stated above, thehierarchies illustrated in FIGS. 11-13 can be based upon a standard,such as ISA 88, ISA 95, or other standard. Any suitable representationthat can be utilized to model an entirety of a plant, however, iscontemplated. Further, the representations shown in these figures can bedirectly implemented into a controller. For instance, data objects inaccordance with any portion of the hierarchies described in FIGS. 11-13can be existent within a controller, together with state machines thatenable creation of such objects.

What has been described above includes various exemplary aspects. It is,of course, not possible to describe every conceivable combination ofcomponents or methodologies for purposes of describing these aspects,but one of ordinary skill in the art may recognize that many furthercombinations and permutations are possible. Accordingly, the aspectsdescribed herein are intended to embrace all such alterations,modifications and variations that fall within the spirit and scope ofthe appended claims. Furthermore, to the extent that the term “includes”is used in either the detailed description or the claims, such term isintended to be inclusive in a manner similar to the term “comprising” as“comprising” is interpreted when employed as a transitional word in aclaim.

What is claimed is:
 1. A system that facilitates data federation,comprising: a processor, coupled to a memory, that executescomputer-executable components, the computer-executable componentscomprising: a configuration component configured to receive firstconfiguration information that defines a mount point of an industrialcontroller, wherein the mount point defines a location in a hierarchicaldata structure where a first subset of the hierarchical data structurestored on the industrial controller connects to a second subset of thehierarchical data structure; and an aggregation component configured toaggregate the first portion of the hierarchical data structure and thesecond portion of the hierarchical data structure at the location basedon the mount point.
 2. The system of claim 1, wherein the hierarchicaldata structure comprises a hierarchical model of an industrialorganization.
 3. The system of claim 2, wherein the hierarchical modeldefines at least one of a plant level of the industrial organization oran enterprise level of the industrial organization.
 4. The system ofclaim 1, wherein the configuration component is further configured toreceive second configuration input that facilitates creation of thefirst subset of the hierarchical data structure in the industrialcontroller.
 5. The system of claim 4, wherein the first subset of thehierarchical data structure comprises a first set of nodes that definefirst hierarchical relationships between first entities relating tocontrol of an industrial asset of an industrial organization.
 6. Thesystem of claim 5, wherein the second subset of the hierarchical datastructure comprises a second set of nodes that define secondhierarchical relationships between second entities of the industrialorganization.
 7. The system of claim 6, wherein the second entitiesrelate to a business operation of the industrial organization.
 8. Thesystem of claim 5, wherein the first set of nodes are associated with aset of data items stored on the industrial controller.
 9. The system ofclaim 2, wherein the hierarchical data structure defines at least a linelevel of the industrial organization, wherein the line level comprisesat least one of an equipment component, a control component, aproduction component, a segment component, or a miscellaneous component.10. The system of claim 1, wherein the computer-executable componentsfurther comprise a controller component configured to convert a flatdata structure to a hierarchical format based on the hierarchical datastructure.
 11. The system of claim 1, wherein the configurationcomponent is further configured to receive second configurationinformation that sets a tag associated with the hierarchical datastructure as one of public or private, and wherein setting the tag aspublic renders the tag viewable from an application that reads data fromthe industrial controller.
 12. A method for federation of data,comprising: defining a mount point for an industrial controller, whereinthe mount point defines a location within a hierarchical data structureat which a first portion of the hierarchical data structure that isstored on the industrial controller connects to a second portion of thehierarchical data structure that is stored on a device that communicateswith the industrial controller; and aggregating the first portion of thehierarchical data structure and the second portion of the hierarchicaldata structure based on the mount point.
 13. The method of claim 12,further comprising defining the first portion of the hierarchical datastructure in the controller, wherein the defining the first portioncomprises defining one or more first nodes that define firsthierarchical relationships between first entities relating to control ofan industrial asset of an industrial enterprise.
 14. The method of claim13, further comprising defining the second portion of the hierarchicaldata structure in the device, wherein the defining the second portioncomprises defining one or more second nodes that define secondhierarchical relationships between second entities of the industrialenterprise.
 15. The method of claim 14, wherein the defining the secondportion comprises defining the second hierarchical relationships betweenthe second entities relating to one or more business operations of theindustrial enterprise.
 16. The method of claim 14, wherein the definingthe first portion or the defining the second portion comprises definingat least one of a line level of the industrial enterprise, wherein theline level comprises at least one of an equipment component, a controlcomponent, a production component, a segment component, or amiscellaneous component.
 17. The method of claim 12, further comprisingat least one of converting a flat data structure to a hierarchicalformat based on the hierarchical data structure.
 18. A computer-readablestorage device having stored thereon computer-executable instructionsthat, in response to execution, cause a computing system including aprocessor to perform operations, the operations comprising: defining amount point of an industrial controller, wherein the mount point definesa node of a hierarchical data model at which a first subset of thehierarchical data model that is stored in the industrial controllerconnects to a second portion of the hierarchical data model that isstored in a device that is networked to the industrial controller; andaggregating the first subset of the hierarchical data model and thesecond subset of the hierarchical data model based on the mount point.19. The computer-readable storage device of claim 18, wherein theoperations further comprise defining the first subset of thehierarchical data model in the industrial controller, wherein thedefining the first subset comprises defining one or more firsthierarchical relationships between first entities relating to control ofan industrial asset of an industrial enterprise.
 20. Thecomputer-readable storage device of claim 18, wherein the operationsfurther comprise defining the second subset of the hierarchical datamodel in the device, wherein the defining the second subset comprisesdefining one or more second hierarchical relationships between secondentities relating to a business operation of the industrial enterprise.